home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1204 < prev    next >
Text File  |  1995-07-25  |  11KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                             S. Yeh
  8. Request for Comments: 1204                                        D. Lee
  9.                                               Netix Communications, Inc.
  10.                                                            February 1991
  11.  
  12.  
  13.                      Message Posting Protocol (MPP)
  14.  
  15. Status of this Memo
  16.  
  17.    This memo describes a protocol for posting messages from workstations
  18.    (e.g., PCs) to a mail service host.  This RFC specifies an
  19.    Experimental Protocol for the Internet community.  Discussion and
  20.    suggestions for improvement are requested.  Please refer to the
  21.    current edition of the "IAB Official Protocol Standards" for the
  22.    standardization state and status of this protocol.  Distribution of
  23.    this memo is unlimited.
  24.  
  25. 1. INTRODUCTION
  26.  
  27.    Operating systems for personal computers do not provide a mechanism
  28.    for user authentication.  However, such a mechanism is crucial for
  29.    electronic mail system since authenticating message sender's identity
  30.    is important in preventing mail forgery.  Hence, adding personal
  31.    computers to an electronic mail network requires an agent (message
  32.    posting server) to authenticate sender's identity and then submit
  33.    mail to the message delivery system (e.g., Sendmail, MMDF) on behalf
  34.    of the sender at a PC.  The Netix Message Posting Protocol is
  35.    developed to be the interface between the message posting server and
  36.    the PC (client).  The protocol is designed to use TCP and is based on
  37.    the command and reply structures defined for Simple Mail Transfer
  38.    Protocol (RFC 821) and File Transfer Protocol (RFC 959).
  39.  
  40. 2. SPECIFICATIONS
  41.  
  42. 2.1.  Command List
  43.  
  44.       USER <SP> <username> <CRLF>
  45.       PASS <SP> <password> <CRLF>
  46.       DATA <CRLF>
  47.       NOOP <CRLF>
  48.       QUIT <CRLF>
  49.  
  50. 2.2.  Reply List
  51.  
  52.       220 Message Posting Service Ready.
  53.       221 Closing Connection.
  54.       250 Command OK.
  55.  
  56.  
  57.  
  58. Yeh & Lee                                                       [Page 1]
  59.  
  60. RFC 1204                          MPP                      February 1991
  61.  
  62.  
  63.       354 Enter mail, end with <CRLF>.<CRLF>
  64.       451 Local error encountered.
  65.       500 Command unrecognized.
  66.       501 Argument syntax error.
  67.       503 Illegal command sequence.
  68.       530 Authentication Failure.
  69.       550 Error.
  70.  
  71. 2.3.  Command and Reply Descriptions
  72.  
  73.       USER <SP> <username> <CRLF>
  74.  
  75.          The USER command informs the message posting server about the
  76.          username of the user trying to submit mail to the network.  The
  77.          required argument for the USER command is a string specifying
  78.          the message sender's username.
  79.  
  80.          The USER command can only be used under three conditions:
  81.  
  82.          - when the session with the message posting server has just
  83.            started;
  84.  
  85.          - right after a message text (terminated by the "<CRLF>.<CRLF>"
  86.            sequence) has been successfully submitted to the message
  87.            posting server;
  88.  
  89.          - right after a USER command that gets the reply code 501.
  90.  
  91.          List of possible reply codes for the USER command:
  92.  
  93.          - 250   The username of the message sender has been accepted.
  94.  
  95.          - 451   Internal error has occurred in the message posting
  96.                  server.
  97.  
  98.          - 501   Syntax error detected in the username argument.
  99.  
  100.          - 503   The USER command has been used under an inappropriate
  101.                  condition (i.e., one that is not specified above).
  102.  
  103.          It is recommended that the message posting server should return
  104.          250 even if the username is not recognized by the message
  105.          posting server, as long as the username is syntactically
  106.          correct.  This is an attempt to prevent the message posting
  107.          server from releasing too much information about the user
  108.          database.  Client should not be able to test the existence of a
  109.          certain username.
  110.  
  111.  
  112.  
  113.  
  114. Yeh & Lee                                                       [Page 2]
  115.  
  116. RFC 1204                          MPP                      February 1991
  117.  
  118.  
  119.       PASS <SP> <password> <CRLF>
  120.  
  121.          The PASS command is used to inform the message posting server
  122.          about the password associated with the username previously
  123.          specified.  The required argument for the PASS command is a
  124.          string specifying the message sender's password.
  125.  
  126.          The PASS command can only be used under two conditions:
  127.  
  128.          - right after a USER command that gets the reply code 250;
  129.  
  130.          - right after a PASS command that gets the reply code 501.
  131.  
  132.          List of possible reply codes for the PASS command:
  133.  
  134.          - 250   The password has been accepted and verified to be
  135.                  correctly associated with the username previously
  136.                  specified.
  137.  
  138.          - 451   Internal error has occurred in the message posting
  139.                  server.
  140.  
  141.          - 501   Syntax error detected in the password argument.
  142.  
  143.          - 503   The PASS command has been used under an inappropriate
  144.                  condition (i.e., one that is not specified above).
  145.  
  146.          - 530   The password provided is not the one associated with the
  147.                  username previously specified.
  148.  
  149.       DATA <CRLF>
  150.  
  151.          The DATA command is used to inform the message posting server
  152.          to get ready to accept a mail message text.  No argument is
  153.          expected.  (This command has the same meaning as the DATA
  154.          command defined in RFC 821.)
  155.  
  156.          The DATA command can only be used under two conditions:
  157.  
  158.          - right after a PASS command that gets the reply code 250;
  159.  
  160.          - right after a mail message text has been successfully
  161.            accepted from the client.
  162.  
  163.          List of possible reply codes for the DATA command:
  164.  
  165.          - 354   The message posting server is ready to accept the mail
  166.                  message text.
  167.  
  168.  
  169.  
  170. Yeh & Lee                                                       [Page 3]
  171.  
  172. RFC 1204                          MPP                      February 1991
  173.  
  174.  
  175.          - 451   Internal error has occurred in the message posting
  176.                  server.
  177.  
  178.          - 503   The DATA command has been used under an inappropriate
  179.                  condition (i.e., one that is not specified above).
  180.  
  181.          Upon receiving the reply code 354 for the DATA command, the
  182.          client should submit the mail message text to message posting
  183.          server and terminate the text by the sequence "<CRLF>.<CRLF>"
  184.          as defined in RFC 821.  If the message text includes the
  185.          "<CRLF>.<CRLF>" sequence, then the sequence is replaced by the
  186.          "<CRLF>..<CRLF>" sequence as defined in RFC 821.  The extra "."
  187.          token will not be included in the final copy of the submitted
  188.          message.
  189.  
  190.          Upon receiving the mail message text terminated by the
  191.          "<CRLF>.<CRLF>" sequence, list of possible reply codes is:
  192.  
  193.          - 250   The mail message text has been successfully queued for
  194.                  delivery.
  195.  
  196.          - 451   Internal error has occurred in the message posting
  197.                  server and the mail message text has not been queued.
  198.  
  199.       NOOP <CRLF>
  200.  
  201.          The NOOP command does not cause any action to be performed by
  202.          the message posting server.  Instead, it tests the status of
  203.          the message posting server.  No argument is expected.
  204.  
  205.          The NOOP command cannot be used under one condition:
  206.  
  207.          - right after a DATA command that gets the reply code 354
  208.            (i.e., when the message posting server is expecting the client
  209.            to submit the mail message text).
  210.  
  211.          List of possible reply codes for the NOOP command:
  212.  
  213.          - 250   The message posting server has not encountered any
  214.                  internal error.
  215.  
  216.          - 451   Internal error has occurred in the message posting
  217.                  server during the current session.
  218.  
  219.       QUIT <CRLF>
  220.  
  221.          The QUIT command is used to terminate the session with the
  222.          message posting server.  No argument is expected.
  223.  
  224.  
  225.  
  226. Yeh & Lee                                                       [Page 4]
  227.  
  228. RFC 1204                          MPP                      February 1991
  229.  
  230.  
  231.          The QUIT command can be used under any condition.  The message
  232.          posting server should always return the reply code 221 for the
  233.          QUIT command.
  234.  
  235. 3. IMPLEMENTATION OF THE MESSAGE POSTING SERVER
  236.  
  237.    There are several issues to be considered when implementing the
  238.    message posting server:
  239.  
  240.    - secured environment
  241.    - port number assignment
  242.    - handling of idle client
  243.    - local/remote password database
  244.    - message queuing
  245.    - handling of message delivery failure
  246.  
  247. 3.1  Secured Environment
  248.  
  249.    The message posting server is responsible for authenticating message
  250.    senders and submitting mail to the message delivery system.  Hence,
  251.    it should be running in a secured environment, such as running on a
  252.    system (UNIX, VMS, MS-DOS) with well restricted physical and network
  253.    access.
  254.  
  255. 3.2  Port Number Assignment
  256.  
  257.    Port 218 is assigned for the Netix Message Posting Protocol.
  258.  
  259. 3.3  Handling of Idle Client
  260.  
  261.    The message posting server should terminate a session if the client
  262.    has been idle for too long, to release the resource allocated for the
  263.    session.
  264.  
  265. 3.4  Local/Remote Password Database
  266.  
  267.    To take advantage of existing password databases, such as the passwd
  268.    file in UNIX, the message posting server can use FTP and POP3 to
  269.    perform the username and password checking with the appropriate
  270.    server.
  271.  
  272.    For network that does not have any password database, the message
  273.    posting server should let the system administrator specify a local
  274.    password file on the host that the message posting server is running.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Yeh & Lee                                                       [Page 5]
  283.  
  284. RFC 1204                          MPP                      February 1991
  285.  
  286.  
  287. 3.5  Message Queuing
  288.  
  289.    The message posting server should attempt to submit accepted messages
  290.    to the message delivery system as soon as possible.
  291.  
  292. 3.6  Handling of Message Delivery Failure
  293.  
  294.    Failure in delivering messages should be handled by the message
  295.    delivery system and the message posting server should not interfere.
  296.  
  297. 4. REFERENCES
  298.  
  299.    [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821,
  300.        USC/Information Sciences Institute, August 1982.
  301.  
  302.    [2] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
  303.        USC/Information Sciences Institute, October 1985.
  304.  
  305. Security Considerations
  306.  
  307.    Security issues are discussed in section 3.1.
  308.  
  309. Authors' Addresses
  310.  
  311.    Shannon Yeh
  312.    Netix Communications, Inc.
  313.    15375 Barranca Parkway, Suite A-215
  314.    Irvine, CA 92718
  315.  
  316.    Phone: (714) 727-9335
  317.  
  318.    Email: yeh@netix.com
  319.  
  320.  
  321.    David Lee
  322.    Netix Communications, Inc.
  323.    15375 Barranca Parkway, Suite A-215
  324.    Irvine, CA 92718
  325.  
  326.    Phone: (714) 727-9335
  327.  
  328.    EMail: dlee@netix.com
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Yeh & Lee                                                       [Page 6]
  339.